StaffScripts
Pagine protette da Password
Autore: Riccardo Data: 23/01/2000 Downloads: 2611 Voto: 3/5 Download P r o v a
Pagine protette da password
Questo script non è totalmente originale, qualcosa di simile si può trovare su javascripts.com.
L'idea di base è abbastanza semplice. Si chiede al visitatore di inserire una USERID ed una PASSWORD in un form. La password sarà il nome di una pagina HTML o una sua parte (estensione esclusa) che viene caricata. Se non si conosce la password non si accede alla pagina ed alle seguenti che così rimangono abbastanza nascoste. Due contributi a questa segretezza vengono dal fatto che la password viene inserita in un apposito campo INPUT di tipo PASSWORD, che come di consueto mentre viene riempito mostra degli asterischi invece dei caratteri, e che praticamene tutti i server web non consentono il browsing della directory del sito che servono.
Quel che ho visto in giro però caricava la pagina segreta a tutto schermo, quindi se dietro l'utente che ha accesso alle pagine segrete c'è una terza persona che l'accesso non lo ha, quest'ultimo potrebbe memorizzare il nome della pagine e così violare la segretezza. Nel mio caso, invece, tutto lo scambio avviene all'interno di un frame, e l'unico indirizzo mostrato nella location del browser è il nome del frame stesso, che è pubblico.
Questo script più di ogni altro necessita di avere a vista i sorgenti per essere compreso, non perché sia difficile quanto perché è facile perdersi nei meandri dei frames, non vi spaventate dunque, ho preferito includerli nella scheda piuttosto che obbligarvi a stamparli.
Cominciamo con i sorgenti, il primo è il frame della pagina d'entrata dove vengono inseriti USERID e PASSWORD:
Sorgente di index.html
JSDIR - Accesso riservato
Come si vede creo una pagina che contiene un solo frame, che occupa il 100% dell'area di schermo, e all'interno di questo carico il file passwordpage.html:
JSDIR - Accesso riservato
All'interno del form faccio inserire una USERID (riservato) ed una password che nel caso dell'esempio sarà proprio la parola password.
All'atto dell'invio del form (invece del submit uso un semplice button) faccio un duplice controllo, verifico che la USERID (campo pwd) corrisponda a quella prevista e che il campo della password (pwd) non sia vuoto. Per questi controlli si veda la scheda del Form Validator. Va da se che di fatto la USERID non ci serve proprio a niente, serve solo a scoraggiare un visitatore inesperto che si trova di fronte a due campi da riempire e che, se riempiti male gli danno degli errori.
È il momento di una precisazione, banale per chi è più esperto, ma non intuitiva per i neofiti. Non conviene controllare anche l'esattezza della password, per far questo la password dovrebbe comparire in chiaro nel sorgente della pagina (come la USERID), quindi sarebbe immediatamente visibile a qualunque programmatore HTML.
Fatti questi due controlli la password viene convertita in lettere minuscole (pass=pwd.toLowerCase();), e poi viene caricata la pagina della password (location.replace(pass + ".html");), che, è importante notare, viene caricata all'interno del frame, non nella finestra principale del browser.
L'uso del metodo replace() ci evita che la URL della pagina riservata vada nella history (cronologia) del browser, così chi dovesse accedere allo stesso computer non avrebbe modo di leggere la pwd inserita.
Dato che abbiamo controllato solo se una pwd è stata inserita, ma non ne abbiamo controllato il valore, ad avvertire l'ignaro visitatore che ha sbagliato la password ci pensa direttamente il browser, con un messaggio che non si aspetterebbe. Infatti, dato che la password stessa è costituita da un file HTML, se la pwd è errata, il relativo file non esisterà, quindi il browser ci risponderà che non riesce a caricare la pagina. E questo dovrebbe essere sufficiente a disorientare perché chi non conosce la pwd, sarà portato a pensare non tanto che la pwd è errata (anzi potrebbe anche essere giusta per quel che ne sa), ma che c'è stato un errore di programmazione del sito. Ci facciamo una brutta figura, è vero, ma almeno raggiungiamo lo scopo della segretezza.
A questo punto viene il bello, entra in gioco l'ultima parte della nostra protezione, cioè proprio il file protetto, che nel nostro caso è password.html:
La pagina non contiene assolutamente nulla, bel c'è solo uno spazio ( ), ma c'è uno script piccolo piccolo. È un altro cambio di pagina, a questo punto viene caricato il primo vero file dell'area riservata del nostro sito (qui si chiama proprio areariservata.html), ma anche in questo caso nel frame interno. La location mostra ancora index.html, ed il nostro visitatore non si sarà accorto assolutamente del cambio di pagina, perché il file password.html, cioè il sorgente appena sopra, è lungo appena 130 bytes e viene caricato, ed immediatamene sostituito, in una frazione di secondo, anche con un modem lento.
Credo che il livello di sicurezza sia abbastanza elevato, non è confrontabile con una protezione a livello di server (in quel caso USERID e PWD risiedono in un database protetto ed è direttamente il server che li chiede e li controlla), ma è più che sufficiente per proteggere delle pagine che contengano dei dati riservati ma non così delicati come, ad esempio, un estratto conto bancario, o "dati sensibili" a norma della Legge sulla privacy (L. 675/96). Un mio cliente ha voluto rendere accessibili solo ai suoi clienti dei dati finanziari pubblici ma di difficile reperibilità che scarica dalla rete, e questa soluzione si è rivelata adatta alle sue necessità.
Vi faccio notare, infine, che:
il fatto che la PWD sia convertita in lettere minuscole non è assolutamente obbligatorio. Risponde all'esigenza di consentire la digitazione della PWD nel modo più veloce possibile, anche a chi usa solo due dita sulla tastiera. Si possono usare anche le maiuscole (a patto di fare bene attenzione poi al nome del file HTML) ma andrà sicuramene a discapito della sicurezza.
se premete sul tasto "indietro" del browser la pagina non cambia, in effetti la pagina precedente è la password.html che contiene l'ultimo script, la cui esecuzione non fa che ricaricare la pagina definitiva;
i sorgenti, se visualizzati con il browser, non rivelano assolutamente nulla;
se fate un "reload" viene semplicemente caricata o la pagina definitiva oppure la pagina d'ingresso. La pagina password.html non viene mai mostrata a schermo né resta attiva abbastanza tempo da essere catturata;
così com'è fatto lo script, USERID e PWD saranno uniche per tutti gli utenti, si possono differenziare creando tanti file password.html che differiscono solo nel nome, quanti sono i nostri utenti, lasciando però invariata la USERID, a meno che non si voglia fare, nel file d'ingresso, un controllo per ogni USERID data ai nostri utenti. Ma resta comunque una cosa inutile dato che la USERID non viene assolutamente usata essendo solo uno "specchietto per le allodole", e che, anzi, potrebbe dare al furbacchione di turno un suggerimento che non è il caso di dargli.
http://www.jsdir.com/staffscripts/script016.asp